Bank Account - MXN

Introduction

This section covers MXN (Mexican Peso) on-ramp specifics. MXN deposits use a per-payment destination CLABE returned at ticket creation time.

Mexico has a single rail. There is no key-lookup utility as in COP, and no source-account registration as in ARS — all on-ramp parameters come back in the ticket creation response, so there is nothing to validate or register before creating the ticket.

How an MXN deposit works

1. Quote a fixed-rate MXN → token conversion (inputCurrency=MXN&inputPaymentMethod=BANK-TRANSFER&outputCurrency=USDC).
2. Create a ticket. MXN carries no rail-specific input block — send only the quote token and the output.
3. Receive deposit instructions in the ticket response: clabe, bankName, accountHolder and expiresAt.
4. Show those instructions to the end-user. They open their Mexican banking app and send the exact MXN amount to that CLABE, from any account.
5. Webhook fires when the deposit is confirmed; the ticket transitions to PAID and the user is credited net of fees.

warning

Amount-locked, not source-locked. Unlike ARS, MXN does not lock the deposit to a payer account — the transfer may come from any Mexican account. The amount is locked: a transfer for a different amount does not settle the ticket.

warning

The API payment method is BANK-TRANSFER. SPEI is the name of the underlying Mexican interbank network — it is not a valid API value and returns HTTP 400.

Ticket creation request body

curl -X POST "https://api.sandbox.avenia.io:10952/v2/account/tickets/" \
-H "Authorization: Bearer eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" \
-H "Content-Type: application/json" \
-d '{
  "quoteToken": "eyJhdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "ticketBlockchainOutput": {
    "beneficiaryWalletId": "00000000-0000-0000-0000-000000000000"
  }
}'

There is no ticketMxnInput — the rail needs nothing from the caller for a payin.

Ticket creation response (MXN-specific fields)

In addition to the standard id field, MXN tickets return the destination CLABE instructions:

{
  "id": "3f21c5b8-2f19-4a0a-9a1c-8e0d5c2b7a41",
  "clabe": "012180001234567899",
  "bankName": "NVIO",
  "accountHolder": "Avenia LLC",
  "expiresAt": "2026-08-12T16:30:10.888Z"
}

Field	Type	Description
id	string (UUID)	Ticket identifier.
clabe	string	The destination 18-digit CLABE the payer must transfer MXN to.
bankName	string	Name of the Mexican bank holding the destination CLABE.
accountHolder	string	Legal name the destination CLABE is registered under. The payer's bank asks for it at confirmation — show it in your UI. Omitted when it cannot be resolved; the CLABE alone still routes the transfer.
expiresAt	timestamp	ISO 8601. The deadline to show the user. After it passes, the deposit can no longer be matched to this ticket.

warning

Treat expiresAt as the deadline, not the CLABE's own lifetime. Avenia requests a 24-hour deposit window, but the window the rail enforces on the CLABE can be longer than the ticket's validity. That asymmetry only matters in one direction: a transfer arriving after expiresAt cannot be matched to the ticket, even if the CLABE still accepts it. Re-quote rather than reusing a stale CLABE.

Reading the deposit back

GET /v2/account/tickets/{id} exposes the same instructions under mexicanFiatSenderInfo, prefixed so they never read as the payer's own account:

Field	Description
depositClabe	Destination CLABE — the account to fund.
depositBankName	Bank holding it.
depositAccountHolder	Name it is registered under.
depositAmount	Exact amount to transfer.
depositExpiresAt	When the instruction stops being payable.

The payer half (name, documentNumber, documentType, clabe, bankName) is omitted until the deposit is matched, and this rail frequently reports the payer as unknown — do not depend on those fields being populated.

Errors

Status	Message	When
403	MXN KYC must be approved before creating MXN tickets	The MXN rail is not unlocked. See KYC - MXN, or KYB - MXN for company accounts.
400	InvalidFieldError: inputCurrency-inputPaymentMethod is invalid	SPEI was sent as inputPaymentMethod on the quote. Use BANK-TRANSFER.

info

Monthly limit: level-1 accounts are capped at 400,000 MXN per direction per month — payin and payout are counted separately.

info

Sandbox testing: the deposit is simulated — no real MXN transfer is required. See Simulate MXN Deposit.

Conclusion

You now have the necessary understanding to create MXN on-ramp tickets, display the destination CLABE instructions to your end-user, and consume the resulting deposit through the MXN bank-transfer pay-in flow.